Los fabricantes de herramientas de código bajo y sin código (LC/NC) se enfrentan a una batalla cuesta arriba tratando de convencer a las personas, especialmente a los desarrolladores profesionales, de usar o simplemente probar sus herramientas y plataformas. Algunas plataformas han incursionado en este mercado, pero la mayor parte del desarrollo de software, sin duda, aún lo realizan profesionales que escriben código. Desde la perspectiva de los fabricantes de herramientas, la falta de interés parece desconcertante. Desarrollo más rápido, costos más bajos, menos errores, implementación más fácil, entornos administrados: ¿por qué alguien rechazaría estas herramientas de visión utópica que les gusta presentar a los fabricantes? ¿Por qué tantos prefieren continuar su batalla con lenguajes difíciles, seguimiento de errores complejos y configuraciones de entornos oscuros? He estado hablando con desarrolladores, leyendo artículos y rastreando foros de discusión para obtener una respuesta a estas preguntas y he recopilado algunas de las razones presentadas. No ayuda a sus carreras. Aprender herramientas de código bajo puede requerir una inversión significativa de tiempo y esfuerzo, pero hay poco valor profesional en aprender una herramienta LC/NC específica. Incluso en el raro caso de que una empresa de desarrollo de software utilice una herramienta LC/NC, es muy probable que el próximo empleador no necesite las habilidades que adquiere un empleado desarrollador al aprender esa herramienta. La mayoría de los trabajos de desarrollo exigen un conocimiento profundo y experiencia con lenguajes y marcos ampliamente utilizados, y ninguna herramienta de código bajo se usa tanto como React, Angular, Python, Java o C#. Muy pocos trabajos de desarrollo requieren conocimientos de herramientas LC/NC y la probabilidad de que un desarrollador encuentre un mejor trabajo o gane más dinero conociendo una herramienta LC/NC es muy baja. Por lo tanto, es mejor que los desarrolladores dediquen tiempo a aprender y perfeccionar una de las innumerables habilidades, marcos y lenguajes que tienen una gran demanda en el mercado laboral. Los desarrolladores pasaron años aprendiendo a escribir código Casi el 70% de los desarrolladores que respondieron a la declararon tener una licenciatura o superior en Ciencias de la Computación o un tema relacionado. Esto significa que la mayoría de los desarrolladores invirtieron años en estudiar programación, aprender varios lenguajes, arquitecturas de sistemas y, en general, practicar y perfeccionar el arte de escribir código. El uso de herramientas LC/NC a menudo significa renunciar a las ventajas que representan su experiencia e inversión ganadas con tanto esfuerzo. Por lo tanto, no sorprende que la mayoría de los desarrolladores prefieran confiar en las habilidades preciadas que ya adquirieron laboriosamente. Encuesta para desarrolladores de Stack Overflow 2021 Si las herramientas LC/NC realmente cumplen lo que prometen, en el futuro ya no será necesario escribir código para crear aplicaciones. La programación pasará a un nivel más alto de abstracción y las aplicaciones se ensamblarán a partir de componentes existentes en lugar de codificarse. Por lo tanto, los programadores esencialmente amenazan con hacer que sus habilidades ganadas con tanto esfuerzo sean redundantes al usar y apoyar el mayor uso de herramientas LC/NC. Por lo tanto, les interesa que las herramientas LC/NC no tengan éxito. A los desarrolladores les importa menos la velocidad Cuando los desarrolladores trabajan para casas de software, se les paga para entregar código que tiene características específicas. Estos incluyen ser fáciles de leer, comprobables, bien estructurados, confiables, eficientes, siguiendo estándares, etc. Los desarrolladores que mantienen aplicaciones moderadamente complejas apreciarán lo importante que es asegurarse de que el código sea lo más simple posible y fácilmente comprensible. Estas cualidades son esenciales para que el código sea mantenible. El código generalmente es revisado por un programador más experimentado que también se preocupa por estas cualidades y refuerza el énfasis en ellas. Es posible que tengan un mayor interés en hacer las cosas más rápido que el desarrollador, pero saben que el código que tiene errores, es ineficiente, está escrito de manera críptica y es difícil de extender es difícil de mantener. Este código incorrecto puede causar muchos problemas y volverse muy costoso en el futuro. Si bien la velocidad a la que se entrega el código es relevante, la forma en que se organiza y escribe el código generalmente tiene prioridad sobre la velocidad a la que se entrega. Por lo tanto, es posible que comercializar la velocidad de desarrollo de las herramientas LC/NC para los desarrolladores no tenga el impacto esperado. Los desarrolladores disfrutan de la codificación La gente es vaga y emocional. Tienen prioridades en conflicto, a menudo son inseguros, inexactos y mienten. A menudo ni siquiera saben lo que están haciendo y por qué lo están haciendo. La gente puede ser muy confusa. Las computadoras son mucho más simples. La computadora simplemente sigue las instrucciones que le dio el programador y si esas instrucciones son incorrectas, el programa falla. La precisión en definir un conjunto de tareas y verlas realizadas de manera inmediata y exacta da a muchas personas una sensación de seguridad y alegría. Hay un elemento creativo en la codificación que muchos desarrolladores realmente disfrutan. La programación es un rompecabezas muy complejo, lleno de acertijos, que abarca docenas de módulos, múltiples capas y miles de líneas de código. Una sola aplicación web puede involucrar fácilmente cinco o más lenguajes diferentes trabajando juntos (por ejemplo, HTML, JS, CSS, C#, SQL). Dar forma a objetos complejos de piezas móviles entrelazadas y verlos funcionar en ciclos sutiles a medida que desarrollan las consecuencias de la lógica integrada en ellos puede ser fascinante y generar una fuerte sensación de logro. La razón por la que existe el software es para hacer la vida más fácil y, fundamentalmente, construimos software para ayudar a las personas a hacer mejor las cosas. Una vez que sepa cómo escribir código, en cualquier idioma, puede construir cualquier cosa que pueda imaginar. Hay alegría en imaginar algo y luego crearlo de la nada, especialmente cuando es útil para los demás y los hace felices. Los desarrolladores no eligen pilas de tecnología Cuanto más tiempo permanece un desarrollador en un proyecto, mejor se vuelve para ampliar la aplicación y más eficiente se vuelve para encontrar y solucionar problemas. Cuando los desarrolladores dejan sus trabajos, a menudo se llevan consigo conocimientos íntimos sobre los detalles intrincados de las aplicaciones. Este conocimiento es muy difícil de recuperar y cuando estos empleados son reemplazados, las aplicaciones que soportan a menudo entran en una fase de inestabilidad y, a veces, incluso de caos. Por lo tanto, si bien las casas de software tienen interés en la estabilidad, los desarrolladores de software a menudo solo se quedan con un empleador durante unos pocos años. Una estrategia que emplean las casas de software para mitigar la pérdida de conocimiento es usar tecnologías que son ampliamente utilizadas y bien conocidas en la comunidad de desarrolladores. El uso de pilas conocidas hace que sea más fácil encontrar personas capacitadas para emplear. También ayuda a esas personas a conocer los entresijos de las aplicaciones creadas con ellos. Los desarrolladores pueden influir en la decisión de qué tecnologías usar para un proyecto, pero comúnmente son los ingenieros senior o incluso la gerencia quienes deciden sobre las pilas usando estos criterios. Por lo tanto, la comercialización de herramientas LC/NC para desarrolladores puede no dar en el blanco. Apostar por una herramienta es arriesgado Los clientes tienden a ser difíciles de precisar a dónde podrían llevar una aplicación en el futuro. Esto es comprensible ya que el futuro es muy difícil de predecir. Por lo tanto, los propietarios de las aplicaciones deben adaptarse a las necesidades cambiantes para garantizar el éxito comercial de una aplicación. Esto a menudo significa modificar los modelos comerciales y cambiar las tecnologías que permiten dichos modelos. Los desarrolladores experimentados saben esto y les gusta construir sistemas abiertos que puedan adaptarse a las necesidades cambiantes en el futuro. La mejor manera de crear tales sistemas adaptables es codificarlos usando lenguajes y marcos bien soportados. Muchas herramientas LC/NC son nuevas, inmaduras y vienen con importantes limitaciones técnicas. Estos límites generalmente no se anuncian y, a menudo, también están escasamente documentados. La única forma en que las casas de software pueden realmente encontrar estos límites es probar una herramienta y construir una aplicación real. La mayoría de las limitaciones solo se harán evidentes después de una inversión significativa de tiempo y esfuerzo. El desarrollo de software es costoso y arriesgado, y estas incógnitas aumentan aún más el riesgo para los desarrolladores, las casas de software y sus clientes. Los bloqueos sellan el trato Muchas plataformas no permiten que las aplicaciones integradas en esa plataforma se exporten a formatos editables genéricos. Bloquean las aplicaciones, vinculando así al desarrollador a la plataforma o requiriendo que reconstruyan su aplicación desde cero. Teniendo en cuenta que los requisitos futuros son inciertos y que las limitaciones de las herramientas LC/NC a menudo permanecen ocultas hasta el final del proyecto, no sorprende que los desarrolladores puedan ser extremadamente cautelosos a la hora de quedarse encerrados. LC/NC ha fallado muchas veces en el pasado Las herramientas de desarrollo visual no son nuevas. Los primeros intentos de desarrollo visual ya se hicieron hace 50 años. Desde entonces, han ido y venido una plétora de plataformas y entornos de desarrollo visual buenos y malos, y ninguno de ellos ha marcado una diferencia significativa en la forma en que se crean las aplicaciones. Cualquiera que apostó por alguna de estas herramientas, invirtió tiempo y energía en aprenderlas y convenció a los clientes para construir sus proyectos en cualquiera de ellas, perdió la apuesta. Esta historia sugiere que es poco probable que alguna de las herramientas con las que nos encontramos hoy siga existiendo dentro de una década. Muchos desarrolladores pueden considerar estos hechos cuidadosamente y decidir que LC/NC es un callejón sin salida. ¿Ahora que? Entonces, ¿LC/NC es una causa perdida y no hay lugar para LC/NC en el mundo del desarrollo de software serio? ¿Pueden los fabricantes de herramientas LC/NC superar de alguna manera estas barreras y motivar a más desarrolladores a usar productos LC/NC? Muchos desarrolladores prefieren el código debido a la falta de confianza en las herramientas LC/NC y la comunicación de marketing que las anuncia. Para convencer a cualquier profesional de usar una plataforma LC/NC, los fabricantes de la plataforma requieren que los desarrolladores confíen en ellos. Para generar esta confianza, los fabricantes de herramientas harían bien en escuchar las inquietudes que plantean los desarrolladores y las casas de software y tenerlas en cuenta al planificar las funciones de la plataforma y al comunicarse con los grupos objetivo. La divulgación honesta y veraz de las limitaciones funcionales, la publicación de formas de superar las limitaciones, aplanar la curva de aprendizaje de las plataformas y permitir la exportación de aplicaciones a formatos editables son, aunque no convenzan a todos los desarrolladores, pasos en la dirección correcta.

Stacks

Target

2022 - HackerNoon Contributor of the Year - Coding

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Low Code

2022 - HackerNoon Contributor of the Year - Psychology

2022 - Software Developer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - Software Developer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Low Code

Nominated for 2022 - HackerNoon Contributor of the Year - Coding

Nominated for 2022 - HackerNoon Contributor of the Year - Psychology

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

Making security fun one episode at a time

8 cosas que a los desarrolladores no les gustan del código bajo y sin código

8 cosas que a los desarrolladores no les gustan del código bajo y sin código

Demasiado Largo; Para Leer

Company Mentioned

Coin Mentioned

Franz Rodenacker

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

8 cosas que a los desarrolladores no les gustan del código bajo y sin código

Demasiado Largo; Para Leer

Company Mentioned

Coin Mentioned

Franz Rodenacker

About Author

ETIQUETAS

Languages

ESTE ARTÍCULO FUE PRESENTADO EN...

HISTORIAS RELACIONADAS